Inter-chip software simulation is increasingly utilized in the development of multi-chip systems in order to verify inter-chip functionality. The multi-chip system development process can lead to inter-chip malfunctions for a variety of reasons. For example, interfaces between integrated circuit chips, such as very large scale integration (VLSI) chips, are often ambiguously documented or missing important descriptions required for correct implementation. Design engineers often concentrate on the internal operational characteristics of integrated circuit chips during the design and verification process at the expense of inter-chip functionality. In many instances, the design of integrated circuit chips for multi-chip products occurs across widely dispersed, geographically isolated locations which often leads to design isolation.
The need for inter-chip software simulation also results because system integration typically comes much later in the design cycle, after the integrated circuit chips have been fabricated into hardware. The system integration phase can take months as chips are debugged and prototyped. Only upon integration is the system addressed in its totality. Thus, many serious design problems typically occur and are debugged during system integration. Moreover, by the time the system integration occurs, system designers who have overall system knowledge are often moved on to other projects.
Furthermore, chip-to-chip interfacing bugs are typically very expensive to fix after actual hardware has been fabricated. For example, one or more chips may need to be redesigned and reprocessed which can be very costly. Moreover, product shipment dates can slip, potentially costing even greater additional dollars in lost revenue. Thus, there is a desire to identify inter-chip bugs before fabricating the chips.
Unfortunately, inter-chip software simulations are often considerably more complex than software simulations of a single chip. In fact, inter-chip software simulations may execute an order of magnitude slower than a single chip software simulation. This performance problem dictates that the design engineer cannot rely on traditional random test generation verification process, which takes many simulation cycles.
In some instances, hardware has been employed to speed up the simulation/verification process. Hardware simulation and verification tools, such as QUICKTURN, commercially available from Quicktum Design Systems Inc., allow design engineers to model their chip designs quickly in hardware, enabling the design engineers to pinpoint flaws and correct the flaws on the spot. These hardware simulation and verification tools execute much faster than their software counterparts. However, while hardware simulators are acceptable for relatively simple, single chips with about a million transistors, hardware simulators are too costly and complex for multi-chip systems, such as computer systems, which can have over 40 chips averaging over 2 million transistors each.
In order to address the performance problems encountered when performing software simulations of large multi-chip systems, simulations are now performed by a combination of hardware models and hardware emulators. A hardware model is a detailed program that is written in a hardware description language such as Verilog or VHDL. This hardware model program is synthesized and converted, and finally one or more VLSI chips are fabricated based on the synthesized and converted program. Hardware models are verified by running the program on a computer with a hardware description language simulator.
A hardware emulator is a program used to verify a hardware model. A hardware emulator is written in any number of programming languages, such as C, C++, and PASCAL, and can be written in a hardware description language, such as Verilog or VHDL. Hardware emulators drive stimuli into hardware models and perform the proper handshaking protocols to communicate with a hardware model. Unlike hardware models, hardware emulators typically do not model all of the low-level details of hardware, in other words, hardware emulators tend to be more behavioral. For example, hardware emulators do not typically model exact timing functionality of the hardware. Also, unlike hardware models, hardware emulators are never synthesized and processed into VLSI chips. Finally, hardware emulators typically run significantly faster than hardware models within simulations. Thus, multi-chip simulations utilize some combination of high complexity hardware models and low complexity hardware emulators in order to verify inter-chip functionality in a reasonable amount of time.
An event is a trigger within a hardware model that fires when a particular sequence of interactions occurs. Examples of typical events include: filling a queue; reaching a certain state in a state machine; and asserting a specific signal or group of signals. Events provide indications of the internal operation of the hardware model, and provide coverage information indicative of which portions of the multi-chip system have been verified.
In a multi-chip functional simulation verification framework, better quality silicon is obtained by improving coverage using inter-chip events. An inter-chip event is a trigger within an interface block of a chip. Inter-chip events are generated within an interface block of a chip by stimuli from one or more adjacent hardware models or hardware emulators.
One problem encountered by verification engineers performing conventional multi-chip simulations which employ hardware models and hardware emulators is that inter-chip events caused by hardware emulators are not distinguished from inter-chip events caused by hardware models. Inter-chip events caused by hardware models are much more meaningful to verification engineers than inter-chip events caused by hardware emulators. Hardware models are used to directly generate the actual corresponding hardware, and contain exact timing and functionality of the corresponding hardware. Since hardware emulators do not contain such exact timing and functionality of the hardware, inter-chip events generated by hardware emulators are often artificial cases which never occur in the actual system.
Prior solutions for coverage in multi-chip simulation environments do not determine if inter-chip events are caused by hardware models or hardware emulators. Thus, inter-chip events detected by these prior systems are less meaningful for reasons stated above. In other words, verification engineers are not certain that any actual chip-to-chip events have occurred. Instead, the verification engineer only knows that either chip-to-chip events or emulator-to-chip events have occurred. As a result, prior solutions do not allow verification engineers to reliably measure inter-chip functionality.
Therefore, there is a need for an improved multi-chip software simulation system which is able to distinguish hardware model caused inter-chip events from hardware emulator caused inter-chip events.